Re: BUG #5856: pg_attribute.attinhcount is not correct.

Поиск
Список
Период
Сортировка
От Bernd Helmle
Тема Re: BUG #5856: pg_attribute.attinhcount is not correct.
Дата
Msg-id 6CF92001890CDD19DB8DDEED@[172.26.14.62]
обсуждение исходный текст
Ответ на Re: BUG #5856: pg_attribute.attinhcount is not correct.  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers

--On 31. März 2011 06:06:49 -0400 Noah Misch <noah@leadboat.com> wrote:

> The best way I can see is to make ATExecAddColumn more like ATExecDropColumn,
> ATAddCheckConstraint, and ATExecDropConstraint.  Namely, recurse at Exec-time
> rather than Prep-time, and cease recursing when we satisfy the ADD COLUMN
> with a merge.  Did you have something else in mind?
>
> Incidentally, when we satisfy an ADD COLUMN with a merge, we do not check or
> update attnotnull:
>
> create table parent();
> create table child(c1 text) inherits (parent);
> alter table parent add column c1 text not null;
> \d child
>
> We could either update attnotnull (and schedule a phase-3 scan of the table)
> or throw an error.  For ALTER TABLE ... INHERIT, we throw the error.  For
> CREATE TABLE ... INHERITS, we add the NOT NULL (and no scan is needed).  I'd
> weakly lean toward throwing the error.  Opinions?

Hmm this looks like the same kind of problem i'm currently faced with when
working on tracking inheritance counters for NOT NULL constraint at the moment
(see
<http://git.postgresql.org/gitweb?p=users/bernd/postgres.git;a=shortlog;h=refs/heads/notnull_constraint>
for a heavy WIP patch). It currently recurses and seems to do the right thing
(tm) for your example above, but i'm far from being certain that the way i'm
undertaking here is correct. It indeed discovered a bug i had in my recursion
code...

--
Thanks
Bernd


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: SHMEM_INDEX_SIZE exceeded on startup
Следующее
От: Bernd Helmle
Дата:
Сообщение: wal_buffers = -1 and SIGHUP